When isochronous services, such as voice or video, are transported over a packet network, some means must be provided for carrying timing information over the network. Several well known methods exist for transmitting a clock over a packet network. Methods that currently are in use include Plesiochronous mode, Synchronous Residual Time Stamp (SRTS) described in U.S. Pat. No. 5,260,978, Fleisher et al., or variant RTS method, Adaptive Clock Recovery (ACR), and combinations thereof. These methods rely either on the availability of a shared clock, as is the case for SRTS, an algorithm to transport physical clock information through a packet network, as is the case for ACR, or just accept the clock problem and work around it, as is the case for plesiochronous mode.
The use of a shared clock is not attractive due to the associated costs for a GPS receiver or wiring, including connectors and the like. The current performance of ACR is not sufficient to meet all telecommunication standards, which typically require absolute time stabilities in the order of 50-20 ns.
A clock transport mechanism should ideally meet a number of requirements. It should be suited for telecommunication applications and meet the relevant standards for telecommunications, such as Bellcore 1244, Bellcore 253 etc. It should not require existing hardware to be modified. The solution ideally should be able to handle clock transportation end-to-end without any modification whatsoever for the intervening network. Generally, the second best alternative is that the solution be applied in a moderately well controlled environment, wherein important nodes in the network and the density of the traffic are controlled. The latter is typically necessary for telecommunications applications that require a limited delay through the network. As such, the solution should be in line with existing Service Level Agreements (SLA's). The solution should also be reproducible, adaptive, and operate in various networks. Different network topologies and different uses of a network create different problems. An ideal clock transport mechanism should be robust against that kind of variability.
FIG. 1 illustrates a typical general purpose architecture for a clock transport mechanism. The clock source has a local clock signal, typically generated by a crystal oscillator. The intention is for this clock signal to be copied from the clock source to the clock copy blocks. The copy blocks have their own local oscillators. These blocks determine the difference between their respective local oscillators and the source clock, and at least present this difference as a correction factor, which can be used either for correction of the actual clock, for instance by using frequency synthesis techniques, so as to align it with the source clock or for correction of data that relate to that clock.
Current methods do not meet these requirements for various reasons. For example, in ACR, the variability of the delay of packets is a problem, independent of the method employed. If an algorithm uses the degree of filling of a FIFO for packets, such as timing packets, the arrival times are determined and the algorithm uses direct statistics on the data. The problem with such an approach is that the delays can be modeled essentially as a stochastic process. Averaging of the packet arrival rate as input for some time recovery mechanism, such as a PLL, does work, but is very slow, as is known from standard signal theory. For instance, if the packet arrival delays have a 1 σ value of 2 ms, and the desired 1 σ for averaged time accuracy is 2 μs, the number of packets that is required to arrive at a solution is 10002=1,000,000. If the real packet rate is 100 packets per second, 10,000 seconds are required. A time constant of 10,000 seconds requires very expensive crystal oscillators or even atomic resonators (the cheapest crystal oscillators start to have problems around 1-10 seconds), which is prohibitive for the solution both in required lock time and cost of the solution. Simply increasing the packet transfer rate is not feasible, as the bandwidth overhead for timing purposes only should remain restricted to a few percent. But 100 packets/s of the minimum length packets for Ethernet already yields 100*84*8=67200 bit/s, which is 0.7% of a 100 Mbit/s Ethernet. Increasing this rate by a factor 10 would decrease the effective low pass frequency by a factor 10, which is still far from the range of cheap crystals, but already uses up a lot of network bandwidth.
The plesiochronous solution is not satisfactory. This solution accepts the fact that there will be ‘slips’, and tries to minimize the frequency of such slips, typically by employing expensive, high accuracy clocks. Accepting slips can be acceptable for voice applications, but for synchronous data applications it can become quite disastrous. If combinations of specific forms of security are associated with the traffic (such as stream ciphering), a slip may result in the loss of a session altogether. This may require the connection to be rebuilt. In modern networks, where many types of service are intermingled, such solutions are not acceptable.
SRTS requires a shared clock to be present. This may be a physical line, but may also be a clock, such as a GPS-based clock. The attraction of this solution is that high qualities for clocking are possible and relatively simple to implement. At the same time, the associated cost for the extra wiring or (backplane) antenna plus receiver (GPS), is quite high. Since cost is one of the main driving factors to get synchronous traffic over packet networks, SRTS-like solutions are not attractive.
Other solutions include NTP (Network Time Protocol), CesiumSpray and the like. Elson, Girod, and Estrin, all from UCLA have recently proposed a relatively high quality solution, under the name Reference Broadcast Synchronization (RBS), as discussed in their article ‘Fine-Grained Network Time Synchronization using Reference Broadcasts’. This article was published as ‘UCLA Computer Science Technical Report 020008’. Reference-Broadcast Synchronization (the contents of which are herein incorporated by reference). In this proposal, nodes send reference beacons to their neighbors using physical-layer broadcasts.
In RBS all nodes that need synchronization share an event in the form of receiving a Reference Broadcast, and utilize time stamping on arrival of packets. The receiving nodes then exchange information about the time of arrival of the synchronization packets according to their local clocks. This is shown in FIG. 2. The event generator sends event packets to the receiving nodes. This method avoids the delays associated with the Send Time (the time between the instruction to send a reference and the actual sending) and the Access Time (The contention time for access to Ethernet). The delay time that is still incurred is the Propagation Time (which is just the physical time for transfer of the packet across the physical medium, typically something related to the speed of light for electric media, and the Receive Time (which is the time between the actual reception, and the detection of it).
For telecomm systems the RBS method has a few shortcomings. The method necessitates a physical broadcast channel. For many existing and future networks, this is far from reality. The use of the method in the paper noted above, in wireless sensors, is a typical example where a physical broadcast medium does exist. But in wired networks that support wireless networks, a physical broadcast channel does not exist. Instead the network consists of many switches with point-to-point connections, such as in UTP Ethernet networks. In such networks broadcasting is performed by copy actions inside the switching elements. In such switches, generally the use of multicasting techniques is preferred.
RBS can be used in point-to-point networks if the switching elements also support the technique. For some networks this may be feasible, but most network operators require freedom of choice for equipment. Thus RBS would have to be accepted by all manufacturers of switches, routers and transceivers before it could be deployed safely. This is not very likely to happen.
RBS, as it is described in the above paper, does not regenerate a physical clock. In the application envisaged in the above paper that is not necessary since the clock mismatches are used to repair measurement values for sensors. Some aspects of RBS, such as the use of regression instead of filtering, are questionable.
The use of time routing is solved in RBS, i.e. getting timing from one domain to another over a node that is in both domains, only if both domains use physical broadcasts, and only to the extent that the lack of synchronous detection is ignored. The lack of synchronous detection accumulates errors over routing points. But worse, in switched networks without RBS support in the switches, the time routing becomes a huge problem, because each hop introduces Access Time, as discussed in the RBS documentation. Another problem with RBS is that it uses duplex connections; all nodes exchange their information.
U.S. Pat. No. 6,658,025 describes a method for network clock synchronization in a packet network that employs an iterative process. Time stamps, providing timing information, are sent from a transmitting network element to a receiver network element, having an oscillator. Expected times for reception are estimated, deviations from the expected time for the time stamps are calculated, and at least one time stamp deviating the most from the estimated expected time is removed. Again, expected times are estimated, compared to the remaining time stamps and at least one time stamp deviating the most is removed. This cycle is repeated until a pre-determined number of time stamps are removed. Using the remaining time stamps, the frequency of the receiver oscillator estimated and adjusted accordingly.
The described iterative process is generally slow due to the mathematical calculations at each stage of the synchronization requiring the history of the compensation. Also, the described iterative process only solves the frequency synchronization problem, but not the problem of phase synchronization, which is more complex.